<value value> style, no space after < and before >

fixed

reserved memory is for hardware only, so KMU usage is fine, DMA usage is fine...

this though is not, this is normal RAM, it needs to be a child of the sram node, see the retention doc in zephyr for an example

so it can be moved here

Should we add zephyr_linker_section/zephyr_iterable_section too? This commit suggests that it's needed for IAR: b937d94

I don't think we have to, as we just perform validation as part of this linker section without creating any new symbols

Could you please check if the assertion is properly triggered for LLVM? (to ensure no silent errors in the future)

not needed any more

... assuming that noone would try to compile the configuration with LLVM

You can explain in comment why do we need to check that - mention that otherwise mcuboot would override its own RAM while copying app image to RAM.

mcuboot_qspi configuration of nrf52840dk uses MCUboot with swap (CONFIG_MCUBOOT_BOOTLOADER_MODE_SWAP_USING_MOVE). It triggers the warning here (false positive).

btw. What do you think about enabling it explicitly to prevent breaking backwards compatibility if the default changes in scope of NCS?

As a follow-up action, we could disable it for all of the nRF Desktop configurations (to reduce memory usage)

Should I open a follow-up ticket for this one?

We could consider using a separate MCUboot private key as the configurations running from RAM are not interoperable with other configurations (similarly as we did for Fast Pair configurations)

btw. We could consider skipping defining BUILD_TIME_DFU_SLOT_ID_INFO_IS_AVAILABLE and simply rely on existence of DFU_SLOT_ID macro: use DFU_SLOT_ID if defined, otherwise rely on dynamic APIs

Consider mentioning about enabling CONFIG_USE_DT_CODE_PARTITION. Otherwise the displayed message might be a bit misleading in case CONFIG_PARTITION_MANAGER_ENABLED=n + CONFIG_USE_DT_CODE_PARTITION=n

do not use FATAL_ERROR here, especially not when asking user to disable partition manager, cause a fatal error here will prevent users from running menuconfig and correct the issue, and are instead forced to do a pristine build.

something which might not be desirable if the have done other customizations already in menuconfig.

If wanting a fatal error, then please turn it into a build time failure, not CMake configure time error.

See also zephyrproject-rtos/zephyr#9573

fixed

Consider mentioning that it's an app-specific assumption (not a generic one). Maybe something similar to:

The validation process assumes a specific RAM layout in DTS - you can refer to the following file as an example: ./configuration/nrf54lm20dk_nrf54lm20a_cpuapp/memory_map_ram_load.dtsi

do not use FATAL_ERROR here, especially not when asking user to disable partition manager, cause a fatal error here will prevent users from running menuconfig and correct the issue, and are instead forced to do a pristine build.

something which might not be desirable if the have done other customizations already in menuconfig.

If wanting a fatal error, then please turn it into a build time failure, not CMake configure time error.

See also zephyrproject-rtos/zephyr#9573

we start to have several devicetree labels trying to achieve similar thing, which is to have the code executed / placed at a specific location.

Until we have some more common way to achieve this on higher level, then I would like to know why the existing CONFIG_SRAM_OFFSET is not suitable in this particular case for the MCUboot build ?

@nordicjm please have a look at this, and do some thinking regarding devicetree node used for features like this one, as well as the multicore TCM etc.
Other places of interest: zephyrproject-rtos/zephyr#91591 github.com//pull/25737

Not blocking comment for this PR, due to closeness to rc, but be prepared for follow-up work in this area.

This Kconfig option is only used in the context of the following linker script:

applications/nrf_desktop/linker/mcuboot_ram_load.ld

If set correctly, the CONFIG_SRAM_OFFSET would work in the context of the MCUboot image. However, in the MCUboot image context, we do not have access to the __rom_region_end symbol of the application image.

Also, you cannot change the CONFIG_SRAM_OFFSET Kconfig option from the default non-zero value using the standard *.conf file, as this is a promptless option. It is difficult to set this option correctly for the MCUboot at the nRF Desktop project level (you would have to force it via sysbuild)

Thanks for the extra details.

Will be good to keep in mind when trying to find a better, more consistent / uniform solution for a recurrent problem on more advanced SoCs.